home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14407 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB
  1. Path: news.mcs.net!usenet
  2. From: Mike Young <mikey@mcs.com>
  3. Newsgroups: comp.lang.ada,comp.lang.c++
  4. Subject: Re: some questions re. Ada/GNAT from a C++/GCC user
  5. Date: Sat, 30 Mar 1996 01:04:25 -0600
  6. Organization: Fen Software, Inc.
  7. Message-ID: <315CDCF9.31AF@mcs.com>
  8. References: <wnewmanDoxrCp.DKv@netcom.com> <4je9ju$174r@watnews1.watson.ibm.com> <ROGOFF.96Mar28134118@sccm.Stanford.EDU> <4jhe1v$m0g@dayuc.dayton.saic.com>
  9. NNTP-Posting-Host: mikey.pr.mcs.net
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0GoldB1 (Win95; I)
  14.  
  15. John G. Volan wrote:
  16. > 
  17. > In article <315AC5E7.3A77@escmail.orl.mmc.com>
  18. > Ted Dennison, dennison@escmail.orl.mmc.com writes:
  19. > 
  20. > >If you want to declare variables later in the code just
  21. > >use a declare block:
  22. > >   declare
  23. > >      Var1 : My_Type;
  24. > >      ...
  25. > >   begin
  26. > >      Var1 := My_Value;
  27. > >      ...
  28. > >   end;
  29. > >
  30. > >This has the added benefit of limiting the scope of Var1 to the
  31. > >begin..end  block of code.
  32. > 
  33. > There is another benefit, but it isn't obvious unless you take into
  34. > account the concurrency aspects of Ada:
  35. > 
  36. > A C programmer would complain about having to introduce an extra
  37. > begin/end block in order to introduce variables.  Isn't the scope
  38. > of a variable well-defined in C, even without this extra baggage?
  39. > It just extends from the declaration to the end of whatever block
  40. > you're already in.
  41. > 
  42. > An Ada programmer would counter that, in Ada, some variables might be
  43. > instances of _task_ types.  By definition, a task object gets created
  44. > when its declaration is elaborated, but it does not get _activated_
  45. > (i.e., it doesn't start executing its statements) until you hit the
  46. > "begin" of the enclosing block.  This guarantees that everything in 
  47.  
  48.   [ ... some worthy thoughts snipped ... ]
  49.  
  50. > 
  51. > C, of course, has no concurrency abstractions built in (nor does C++,
  52. > last time I checked), so, gee, I guess this isn't an issue in C. :-)
  53.  
  54. ============
  55. Hmmmm. Lacking a language based synch method doesn't mean we always go 
  56. straight to the semaphore library. I commonly use thin wrappers to guard 
  57. precious resources -- for example: mutexes, semaphores, files, 
  58. or database sessions. Local scoping allows precise control of lifetimes, 
  59. and ensure release even when exceptions are possible:
  60.  
  61. void foo ()
  62. {
  63.    //-- some setup code here, perhaps
  64.    ...
  65.    {               // local scope
  66.      LocalMutex<BazType> foo(mutexHandle);
  67.      BazType & bar = foo.openResource();
  68.      ...           // use the protected resource
  69.    }               // end local scope. LocalMutex releases the resource
  70.    ...
  71. }
  72.